NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part2/10002

Internet Message Format | 1996-08-05 | 3.6 KB

Path: camelot.dsccc.com!not-for-mail
From: [e-mail] (Kevin Cline)
Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
Subject: Re: C/C++ knocks the crap out of Ada
Date: 5 Mar 1996 10:51:25 -0600
Organization: DSC Communications Corporation Switch Products Division
Message-ID: <4hhred$[e-mail]>
References: <[e-mail]> <4h8r0v$[e-mail]> <4hbj2b$[e-mail]> <[e-mail]>
NNTP-Posting-Host: sun152.spd.dsccc.com

In article <[e-mail]>,
AdaWorks <[e-mail]> wrote:
>Kevin Cline ([e-mail]) wrote:
>
>: In article <4h8r0v$[e-mail]>,
>: Jay Martin <[e-mail]> wrote:
>: >[e-mail] (Kevin Cline) writes:
>: >
>: I didn't say that; I said that Ada was not suitable for most software
>: development because Ada programs that did serious work could not
>: be ported.  Actually, I have used Ada-83 to build a good-sized application
>: (50K SLOC) and there is a lot I liked about it.  But porting that application
>: from SunOS to SGI IRIX was much more difficult than porting comparable C++
>: programs.  For whatever reason, the Ada-83 standard simply did not go
>: far enough.
>
>  How odd.
>
>  Many of have exactly the opposite experience. It is true that one can
>  write Ada programs that are non-portable.  It is also true that a
>  correctly designed Ada program will be as portable as a program
>  written in any other language.
>
>  The trick is designing at the right level of abstraction. Machine and
>  operating system dependencies should not be the controlling factor in
>  designing an application.  Unless, of course, the targeted application
>  is, itself, a binding to some such dependency.
>

Well, I will now enumerate the difficulties I had porting an Ada program
with a Motif user interface from the TeleSoft compiler for Sparc-SunOS to
the Verdix compiler for MIPS/IRIX circa 1990:

1. The TeleSoft compiler came with the IEEE Ada-POSIX bindings.
   The Verdix compiler did not; instead it supported a Verdix-defined
   API for UNIX services that was radically different.

2. The syntax (pragmas) required to call C code from the two compilers
   differed.

3. Although both compilers were 'validated', they both failed to compile
   certain LRM-comformant code, and generated erroneous object code in
   some other cases.  I concluded that the Ada validation suite
   was rather incomplete, and actually proved very little about compiler
   quality.

4. The debuggers were extremely poor and buggy when compared to dbx.
   In particular, the user interface to the Verdix debugger was one
   of the most bizarre I have ever seen.

6. Because Ada-83 did not allow passing procedures as parameters to
   other procedures, there was no reasonable way to create an
   API to an event-driven GUI library like MOTIF.

5. The compilers had two completely different API's for calling
   X and MOTIF services.

The lack of industry standard Ada bindings to these common OS
services combined with the high expense and poor quality of the
available Ada-83 compilers made development a medium-scale portable
UNIX application in Ada much more expensive and difficult than
developing the same application in C.

Perhaps the emergence of GNAT has changed all this, but it is going
to be hard for Ada to keep up.  To use Ada in my work today, I would
require an API to CORBA, Tcl/Tk, and the Solaris real-time facilities
(itimers, etc.) and a runtime that efficiently mapped Ada tasks to
Solaris threads.
--
Kevin Cline